Many software applications (or simply, applications) are developed from an object-oriented point-of-view. These applications consist of “objects” that are self-contained modules of data and associated processing. There is frequently a need to store object data in a persistent data store. Typically, a relational database is used to provide the persistent data store because the technology for relational databases is mature and is widely available.
FIG. 1 is a block diagram of selected aspects of a conventional approach for storing object data on a relational database. Object 110 is a software object developed according to an object-oriented programming language such as Java, C++, and the like. Object 110 includes persistent data such as attribute 112. An “attribute” is a data element that specifies a characteristic of object 110. Relational database 130 stores data (e.g., in table 132) using an organizational model that is based on set-oriented query and update statements.
Persistence layer 120 maps the object-oriented domain of object 110 to the relational domain of database 130. Typically persistence layer 120 includes an object-relational schema 122 to define the mapping between the object-oriented domain and the relational domain. For example, schema 122 specifies that attribute 112 is mapped to row 134 of table 132.
There are a number of disadvantages to the conventional approach for storing object data on a relational database. First, the conventional approach of saving and restoring the attributes of each single object is not suitable for mass data transfers. Also, the conventional approach limits the use of database views because schema 122 provides a fixed mapping between objects and tables. The conventional approach also involves the additional administrative overhead of generating schema 122. Finally, the traditional approach does not distribute persistence and transaction management in distributed systems.